ci: take the lua and python plugins back; drop perl and the theme manager - #9

Chained on #8. That PR left the scripting plugins out of the Windows build;
this one brings back the two we want — lua and python — and removes the two
nobody does: perl and htm/thememan.

lua

The only blocker was gvsbuild's recipe (it runs .\msvcbuild through
CreateProcess, which cannot launch a .bat). build-deps.ps1 now builds
LuaJIT itself — a pinned v2.1 commit, compiled by msvcbuild.bat under
vcvars64 via a generated .cmd so cmd /c's quote-stripping never meets the
spaces in the Visual Studio path — and installs it into the gvsbuild prefix
exactly where poxchat.props already looks (lua51.lib, bin\lua51.dll,
include\luajit-2.1). copy.vcxproj's existing Exists() condition stages
the DLL with zero project changes. lgi and --enable-gi stay out: the plugin
needs neither, they only ever gave Lua scripts GObject bindings.

python

The plugin is a cffi embedding, so it needs three things: cffi in the build
interpreter (generate_plugin.py renders python.c through it),
python313.lib to link (setup-python's install has include\ and libs\
laid out exactly as python3.vcxproj expects), and an interpreter beside the
binary at run time. The last comes from CPython's embeddable package —
pinned by version and sha256 in build-deps.ps1 — staged whole into the tree,
so users need no system Python. python313._pth's . entry keeps the install
dir on sys.path, which is where copy.vcxproj already drops
_cffi_backend*.pyd.

The minor version is pinned in four places that move together (workflow
python-version, Python3Lib in the props, $PythonEmbedVersion+hash in
build-deps.ps1, the python313.* names in the installer); every one of them
says so in a comment. The props' default YourPython3Path said C:\Python314
against Python3Lib=python313 — aligned on 3.13.

The runtime is staged after the copy project and before the import check
and smoke test, so hcpython3.dll → python313.dll is judged against the tree
that ships. It never overwrites: gvsbuild's sqlite3.dll is already staged,
and python's _sqlite3.pyd is content with any current sqlite beside it.

installer

perl and thememan leave every section they touched — [Components],
[Registry] (the .hct associations), [Run], [Files], [Icons], and
the Pascal [Code] that downloaded Perl/Python/dotnet installers at install
time. CheckDLL, CheckVC2013Install and CheckDotNetInstall existed only
for those flows and go with them; idp now fetches just vcredist and the
spelling dictionaries. The python component stops meaning "requires Python
3.8 on the system" and ships the bundled runtime as ordinary [Files]
entries, joining lua in the normal install type.

While in there: the [Files] list never learned about a dozen DLLs the
staged tree carries (sqlite3.dll, the gdk-pixbuf loader chain, the
libcurl→psl→ICU set), so an installed tree — unlike the portable zip — was
missing them. Added, with the conditionally-staged set mirrored as
skipifsourcedoesntexist to match copy.vcxproj's optionality. With no
unbuildable payloads left, -f installer=true should now compile.

Cost

build-deps.ps1 changed, so the first run re-keys the cache — but
restore-keys resumes from #8's stack and gvsbuild skips everything already
built; LuaJIT itself is under a minute and the embeddable zip is an 11 MB
download.

🤖 Generated with Claude Code